Mainstream processor chips, both in high performance and low power segments, are increasingly integrating additional functionality such as graphics, display engines, security engines, PCIe™ ports (i.e., ports in accordance with the Peripheral Component Interconnect Express (PCI Express™ (PCIe™)) Specification Base Specification version 2.0 (published 2007) (hereafter the PCIe™ specification) and other PCIe™ based peripheral devices, while maintaining legacy support for devices compliant with a PCI specification such as the Peripheral Component Interconnect (PCI) Local Bus Specification, version 3.0 (published 2002) (hereafter the PCI specification).
Such designs are highly segmented due to varying requirements from the server, desktop, mobile, embedded, ultra-mobile and mobile Internet device segments. Different markets seek to use single chip system-on-chip (SoC or SOC) solutions that combine at least some of processor cores, memory controllers, input/output controllers and other segment specific acceleration elements onto a single chip. However, designs that accumulate these features are slow to emerge due to the difficulty of integrating different intellectual property (IP) blocks or agents on a single die. This is especially so, as IP blocks can have various requirements and design uniqueness, and can require many specialized wires, communication protocols and so forth to enable their incorporation into an SoC. As a result, each SoC or other advanced semiconductor device that is developed requires a great amount of design complexity and customization to incorporate different IP blocks into a single device.
In REQ-to-GNT protocol (and alike) implementation, an IP agent coupled to an interconnect (or fabric, bus) has to obtain an ownership or access rights of the interconnect by sending a request (REQ) signal to an arbiter and receiving a grant (GNT) signal from the arbiter before it can transmit a transaction onto the interconnect. Typically, as shown in FIG. 1, a temporary storage (hereinafter referred as transaction buffer) is implemented to buffer transactions or transaction related data (retrieved from transaction data storage such as registers) for which a “REQ” has already been placed on an IO fabric subsystem as an example. When “GNT” arrives, relevant transaction is pulled from the transaction buffer and pushed into IO fabric subsystem as shown in FIG. 1. As a result, the depth of this transaction buffer is dependent on the REQ-to-GNT latency for given bandwidth requirement and latency tolerance. When an IP agent is moved within an IO subsystem fabric, or changes its latency requirements, the REQ-to-GNT latency changes and impacts the depth of transaction buffer.